When devices within a data processing system require a processing unit within the data processing system, typically the CPU, to perform a service routine, they will typically issue an interrupt to that processing unit. When an interrupt is received by the processing unit whilst it is executing a main process, the processing until will typically temporarily interrupt the main process under execution, and instead execute an appropriate Interrupt Service Routine (ISR) in order to handle the interrupt. The devices may be on the same chip as the processing unit, or may be off-chip. In a typical data processing system there will often be multiple devices which can issue such interrupts, and since the processor cannot simultaneously execute the ISRs defined by the plurality of interrupts, it is known to provide an interrupt controller for receiving the various interrupts, and prioritising between them. Hence, interrupts from certain devices (for example a hard disk drive) can be given higher priority than interrupts from other devices (for example a keyboard).
There are a number of sources of delay which can affect the speed at which interrupts are handled within the data processing system. Firstly, as mentioned earlier, the interrupt controller may need to arbitrate between multiple interrupts, and accordingly the handling of some interrupts can be delayed whilst other higher priority interrupts are handled first. Additionally, the speed with which the processing unit can accept the interrupt once it is received by the processing unit, and can hence begin execution of the appropriate ISR, will depend on what instructions are being executed by the processing unit when the interrupt is asserted to the processing unit. Typically the processor will have to complete execution of any instruction that it is currently executing, before it temporarily interrupts that process, and instead executes the ISR. The number of cycles that may be required to complete execution of an instruction will vary, and can be large. For example, if the instruction is a memory accessing instruction then in a worst case scenario it may take several hundred cycles to complete execution of the instruction, as it may be necessary (a) to access very slow memory, (b) to cause a page fault in a virtual memory system which requires a new page walk, etc. In some situations, it may be necessary to complete execution of a group of interrelated instructions before executing the ISR. For example, on an ARM processor this might happen if the group of instructions manually turns off interrupts at the start of the group and re-enables them at the end. This might happen, for example, when updating the configuration of the interrupt controller itself.
In some implementations, it is important for certain devices that may issue interrupts to have reliable behaviour with regards to the timing of the interrupt response generated by the processing unit as a result of handling an interrupt. As an example, manufacturers of hard disk drives are continually seeking to increase the speed of rotation of the disks, and decrease the distance between the tracks, in order to improve access times and improve the density of information which can be stored. Such a disk drive may, for example, issue an interrupt to cause the processing unit to execute an ISR in order to provide some control signals used to control the positioning of the read and write heads. As the speeds at which the disks rotate increase, and the distances between the tracks decrease, it is becoming more important for the interrupt response timing to be managed more carefully.
Another example is in the area of automotive engine control, where the engine management system may issue interrupts periodically in order to cause the processing unit to execute ISRs in order to provide certain critical control information. Again, the timing of the interrupt response can be important.
Whilst the ability to prioritise interrupt requests, so that the interrupt controller can allow high priority interrupts to be forwarded to the processing unit in preference to lower priority ones, assists in ensuring that high priority interrupts are forwarded on to the processing unit at the earliest possible time, the variation in the time taken by the processing unit to actually begin processing the interrupt, depending on what instructions are being executed at the time the interrupt is received, produces a significant amount of variation, also referred to herein as jitter, in the timing of the interrupt response. This jitter can cause errors in the real time control calculations of the devices reliant on the interrupt response, and causes the control to be less accurate. Considering the earlier example of hard disk drives, this jitter can ultimately constrain the degree to which the track widths can be reduced.
Up until now, the only way to seek to alleviate this problem has been to seek to provide mechanisms that reduce the maximum latencies that can be expected with regards to interrupt responses, thereby constraining the jitter. However, this is non-trivial, and tends to place significant constraints on the manner in which instructions are executed by the processing unit, to seek to ensure that no instructions are required to be executed by the processing unit that will take more than a predetermined number of clock cycles to complete, this predetermined number being chosen having regard to the maximum latency allowed with regards to interrupt responses.
Accordingly, it would be desirable to provide an improved technique for constraining the jitter in interrupt response timing when handling interrupts within a data processing apparatus.